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Description 

MULTI-PHONE PROGRAMMING 
APPLICATION 

Background of Invention 

[0001] This invention relates generally to automating the provi- 
sioning process for distribution of wireless radiotelephone 
handsets, and particularly to methods and apparatus for 
provisioning handsets to meet customer specifications for 
handsets and communication services. The methods es- 
pecially limit the need for human interfacing in the pro- 
cess and provide automated quality assurance to control 
product quality. 

[0002] Rapid growth has characterized various telecommunica- 
tion industries, most especially the mobile telephone in- 
dustry. Because of this rapid growth, there are now many 
different manufacturers of the radiotelephone handsets 
used in the mobile phone industry. In addition to the mul- 
tiple manufacturers, there are also multiple service 
providers or carriers. To further complicate matters, each 



carrier can use a different and incompatible mobile phone 
technology to power its network. Today, there are ap- 
proximately 10 radiotelephone handset manufacturers, at 
least 4 major service providers, and at least 4 different 
technologies for mobile phones. This makes it especially 
complicated to get phones provisioned properly such that 
all necessary information required by either the radiotele- 
phone handset seller or the service provider. Manufactur- 
ing technology steadily expands the numbers of handset 
models and arrays of selectable handset features. Simi- 
larly, telecommunication service providers adapt features 
of broadcast systems and business practices to accommo- 
date available hardware features, including differentiating 
services based on geographic and temporal factors. The 
services must address both legacy hardware and newly 
emerging hardware. And distributors of handset packages 
and service agreements order a wide diversity of handsets 
and service options to sell, based on marketing needs. 
[0003] Radiotelephone handsets are typically provisioned at dif- 
ferent stages in manufacture, distribution, and use to in- 
stall data for phone operation with diverse service net- 
work functions. A provisioning process is, in part, a se- 
quence of operations for encoding reference data and 



program routines into radiotelephone handsets 
(hardware). This enables and authorizes the handsets to 
communicate via one or more telecommunication systems 
(services), and makes available handset features for the 
user to access service features. Provisioning typically re- 
quires different processes specific to many different hard- 
ware types and service systems, and each provisioning 
process is typically done piecemeal. Therefore, the work 
of provisioning is complex and demanding of key re- 
sources, especially of human direction and input. Provi- 
sioning steps typically occur in vendor factories, in service 
centers, and at distributor outlets, culminating in some 
tasks required of the user, i.e. the ultimate customer. 
[0004] Accordingly, methods and systems are highly valued that 
can improve provisioning efficiencies while accommodat- 
ing ongoing changes in the process. U.S. Patents 
5,603,084 to Henry, 6,223,028 to Chang, 5,297,191 to 
Cerszberg, and 5,754,954 to Cannon each teach systems 
for remote, one-on-one programming of radiophones, for 
use at point-of-sale by a retailer or post-sale by an end- 
user. 

[0005] U.S. Patent 5,491,740 to Ellis provides a mechanical de- 
vice programmed to physically enter key strokes into 



handsets for selecting phone and carrier features. 

[0006] U.S. Patents 5,926,756 to Piosenl<a, 5,974,311 to Lipsit, 
and 6,487,403 to Carroll each provide computer-con- 
trolled, one-on-one programming of telecommunication 
devices for network operation at their points-of-sale. 

[0007] U.S. Patents 6,029,143 and 6,393,408 to Mosher and 

5,887,253 to 0"Neil teach systems to inventory and dis- 
tribute pre-packaged and/or pre-programmed phone sets 
for various manufacturing vendors and cellular service 
providers. Additionally, the Mosher patents disclose the 
possibility of a programming step as part of the inventory 
and distribution system. 

[0008] There remains in the field a need for an improved method 
of provisioning radiophone handset with data and pro- 
grams for activation and operation. The improved method 
encompasses more automation and less human interac- 
tion while still maintaining the ability to provision hand- 
sets made by a variety of manufacturers for use by many 
different service providers. 
Summary of Invention 

[0009] In this text the terms phone, radiophone, and radiotele- 
phone are used interchangeably. "Handset unit" is syn- 
onymous with these terms. The invention provides a 



method and apparatus for provisioning radiotelephone 
handsets in which one preferred embodiment is a soft- 
ware application comprising methods and apparatus for 
provisioning radiotelephone handsets. The invention pro- 
visions multiple radiotelephone handset types with mini- 
mal user interaction, gathering and loading information 
into the radiotelephone handsets automatically. The 
multi-phone provisioning application is typically net- 
worked, so that administrative and management users can 
load shared application information with customer and 
handset specifications at either a remote computer termi- 
nal or the local computer controlled provisioning inter- 
face. Once the necessary data is entered by an adminis- 
trator or manager, the invention then allows an operator 
to automatically provision multiple radiotelephone hand- 
sets with minimal user interaction. As a separate optional 
step, the invention has a built in quality control verifica- 
tion step that can automatically verify and monitor the 
provisioned radiotelephone handsets for meeting specifi- 
cations. 

[0010] One embodiment of the invention provides a universal 
provisioning system for radiotelephone handset units of 
varying model, manufacturer, and technologies. The sys- 



tern includes an interface liaving at least one universal 
connector adapted for connection to radiotelephone 
handsets having different specifications. A computer is 
operably connected to the interface, and memory storage 
in communication with the computer contains provision- 
ing and instruction data for a specified radiotelephone 
handset connected via the interface. The system includes 
software for verifying connection of the specified handset 
and automatically transferring the provisioning data to 
handset memory storage via the interface in accordance 
with instruction data. 

[0011] The universal provisioning system can include additional 
workstations operably connected via metallic wire, ra- 
diofrequency communication, infrared communication, 
fiber optic cable, and the like, and combinations thereof. 

[0012] The memory storage can be random access memory, non- 
volatile hard drive storage, non-volatile flash memory, 
volatile flash memory, removable magnetic media storage, 
optical storage, magnetic tape storage media, EEPROM 
memory, and the like, and combinations thereof. 

[0013] The provisioning data can include roaming instructions, 
user features, number assignment module settings, 
browser and short message service settings, phone book 



entries, date book entries, message settings, carrier spe- 
cific settings, user specific settings, and the like, and 
combinations tliereof. 
[0014] The instruction data can include production build request 
number, quantity of phones to provision, carrier type, 
customer identification data, starting part number, final 
part number, handset manufacturer, handset technology 
type, handset model number, and the like, and combina- 
tions thereof. 

[0015] Another embodiment of the invention includes an auto- 
mated method of provisioning radiotelephone handset 
units. The method includes: (a) generating a build request 
comprising a radiotelephone handset specification and 
provisioning and instruction data for the specified hand- 
set; (b) storing the build request in a memory storage 
medium in communication with a computerized provi- 
sioning system; (c) retrieving data from the build request; 
(d) connecting the provisioning system to a handset in ac- 
cordance with the build request specification; and (e) au- 
tomatically transferring the provisioning data to memory 
storage of the connected handset in accordance with the 
instruction data. 

[0016] Another preferred embodiment of the invention includes 



an automated method of provisioning a plurality of ra- 
diotelephone handset units. The method includes: (a) 
generating a plurality of build requests comprising ra- 
diotelephone handset specification data and provisioning 
and instruction data for the specified handset; (b) storing 
the build requests in a memory storage medium in com- 
munication with a computerized provisioning system; (c) 
selecting an available one of the build requests from the 
storage medium; (d) displaying handset specification data 
from the selected build request; (e) connecting the provi- 
sioning system to a handset in accordance with the speci- 
fication data display; (f) querying the connected handset 
via the provisioning system to compare connected hand- 
set specification data with the build request specification 
data; and (g) automatically transferring the provisioning 
data to memory storage of the connected handset in ac- 
cordance with the instruction data. 
[0017] The generating and storing can be performed on a work- 
station networked with the computerized provisioning 
system. The generating step can also include: (1) entering 
a production build request number; (2) entering a quantity 
of phones to provision; (3) selecting a carrier type; (4) se- 
lecting a customer; (5) entering a starting part number; (6) 



entering a final part number; (7) selecting a handset man- 
ufacturer; (8) selecting a handset technology; (9) selecting 
a handset manufacturer's model number; (10) any combi- 
nation thereof; or the like. 

[0018] The retrieving step can also include: (1) selecting a pro- 
duction build request number; (2) displaying the final part 
number; (3) displaying the handset manufacturer; (4) dis- 
playing the handset manufacturer's model number; (5) 
displaying an image of the handset; (6) displaying the 
customer name; (7) any combination thereof; or the like. 

[0019] The handset specification data that can be displayed in- 
cludes the final part number, the handset manufacturer, 
the handset manufacturer's model number, the customer 
name, or the like, or any combination thereof. 

[0020] The querying can include: (1) communicating with the 
handset; (2) determining the manufacturer and model 
number of said handset; (3) comparing the connected 
handset's manufacturer and model number with the re- 
quested manufacturer and model number; (4) allowing the 
operator to continue to connect a different handset based 
on the result of the comparison; (5) a combination 
thereof; or the like. 

[0021] The generating and storing steps can be performed by a 



manager or someone other than an operator. 
[0022] The method can also include inspecting the memory stor- 
age of the handset to verify provisioning data integrity. 
The inspecting typically includes: entering a production 
build request number; connecting the handset according 
to the build request data associated with the production 
build request number; comparing the provisioning infor- 
mation in the memory storage of the handset to the pro- 
visioning data associated with the production build re- 
quest number; marking the handset with a passing indi- 
cator if the provisioning information matches the provi- 
sioning data; repeating the connection, comparison, and 
marking on the remaining handsets described by the pro- 
duction build request number; determining whether the 
production build request passes or fails based on the in- 
struction data associated with the production build re- 
quest number and returning a pass/fail for the production 
build request; sending failed handsets from a passing 
production build request to a repair station; and sending 
all handsets from a failing production build request to an 
area for segregation. Additionally, the data gathered from 
the inspecting step is stored to a storage medium either 
digitally or in hard copy to generate reports based on the 



data. 

Brief Description of Drawings 

[0023] Fig. 1 is a system schematic for provisioning radiotele- 
plione liandsets according to one embodiment of the 
present invention. 

[0024] Fig. 2 shows illustrative administrative database tables 
used to store various provisioning information for the 
provisioning system of Fig. 1. 

[0025] Fig. 3 is a flow diagram for a manager build setup to gen- 
erate production build requests according to one embodi- 
ment of the present invention. 

[0026] Fig. 4 schematically shows operator interactions with a 
provisioning interface for provisioning radiotelephone 
handsets according to one embodiment of the present in- 
vention. 

[0027] Fig. 5 is a flow scheme for a quality control process for 

verifying provisioning of radiotelephone handsets accord- 
ing to one embodiment of the present invention. 

[0028] Fig. 6 shows a typical function select and access autho- 
rization screen for the application software according to 
one embodiment of the present invention. 

[0029] Fig. 7 shows an administrative setup main screen for the 
application software of Fig. 6 according to one embodi- 



ment of the present invention. 

[0030] Fig. 8 sliows a series of menu screens used as part of tlie 
Administrator Setup process for entering radioteleplione 
liandset manufacturer information into tlie application 
software of Fig. 6 according to one embodiment of tlie 
present invention. 

[0031] Fig. 9 sliows a series of menu screens used as part of the 
Administrator Setup process for entering radiotelephone 
handset model information into the application software 
of Fig. 6 according to one embodiment of the present in- 
vention. 

[0032] Fig. 10 shows a series of menu screens used as part of the 
Administrator Setup process for entering customer 
(service provider) information into the application soft- 
ware of Fig. 6 according to one embodiment of the 
present invention. 

[0033] Fig. 11 shows a series of menu screens used as part of the 
Administrator Setup process for entering item number in- 
formation into the application software of Fig. 6 according 
to one embodiment of the present invention. 

[0034] Fig. 12 shows a series of menu screens used as part of the 
Administrator Setup process for entering user information 
into the application software of Fig. 6 according to one 



embodiment of the present invention. 

[0035] Figs. 13A and 13B togetlier show a series of menu screens 
used as part of the l^anager Setup process to generate a 
new Build Request in the application software of Fig. 6 ac- 
cording to one embodiment of the present invention. 

[0036] Figs. 14A and 14B together show a series of menu screens 
used as part of the Manager Setup process to edit an ex- 
isting Build Request in the application software of Fig. 6 
according to one embodiment of the present invention. 

[0037] Figs. 15A, 15B, and 15C together show a series of menu 
screens used as part of the Provisioning aspect of the Op- 
erator Application process to provision the radiotelephone 
handsets using existing information already loaded into 
the application software of Fig. 6 according to one em- 
bodiment of the present invention. 

[0038] Figs. 16A, 16B, 16C, and 16D together show a series of 
menu screens used as part of the Quality Assurance as- 
pect of the Operator Application process to verify the pro- 
visioning data is correctly loaded into the radiotelephone 
handsets using existing information already loaded into 
the application software of Fig. 6 according to one em- 
bodiment of the present invention. 
Detailed Description 



[0039] In one preferred embodiment shown in Fig. 1, a provi- 
sioning system 5 includes a networl<ed, computer-con- 
trolled provisioning interface 10 that has a video display 
interface 12 and user input interface, e.g. a keyboard 14, 
for interaction with an operator. The provisioning inter- 
face 10 includes the provisioning Application Database 
(SDBA) 16, into which provisioning reference data is im- 
ported and formatted for provisioning use. The reference 
data is obtained via a network 18, for example a local or 
wide-area network (LAN, WAN) or the internet. The provi- 
sioning system 5 downloads the reference data from other 
storage databases (SDBV) 30, (SDBS) 40, and (SDBD) 50 
owned respectively by multiple radiophone vendors, 
phone service providers, and distributors, who may sub- 
scribe to be served by the provisioning system 5. 

[0040] A radiotelephone handset unit 20 that is to be provisioned 
is connected to the provisioning interface 10 using a 
standardized interface connector 22 such as a Universal 
Serial Bus (USB) interface. The USB interface 22 connects 
to the provisioning interface 10 using a conventional USB 
connector 24, and preferably connects to the handset 20 
in a similarly standardized connector 26. The USB inter- 
face 22 preferably maximizes compatibility between 



handset outlets 26 and provisioning interface outlets 24. 
[0041] The invention is enabled for multiple platforms to be 

compatible with available cellular phone technology, for 
example including TDMA, CDMA, GSM, 2G, 2.5G, IRXX, 
3G, UMTS. The invention will also be adaptable to other 
standards as they become available. The provisioning of 
handsets makes use of existing telecommunication stan- 
dards, including IS-136, IS683a, IS-707, IS-95, IS-94. 
Evolving standards will be adopted as they are imple- 
mented. 

[0042] Additionally, the invention contemplates multiple types of 
universal connectors. The most popular and universal 
connector known in the art today is the USB connector. 
Possible connectors currently available in the art include 
male USB Type A connector, male USB Type B connector, 
male Mini USB connector, male Mini USB 2.0 connector, 
male 4-pin IEEE-1394 connector, male 6-pin IEEE-1394 
connector, female USB Type A connector, female USB Type 
B connector, female Mini USB connector, female Mini USB 
2.0 connector, female 4-pin IEEE-1394 connector, female 
6-pin IEEE-1394 connector and combinations thereof. USB 
refers to the USB-IF supported USB specifications currently 
available and all future derivations and revisions of the 



specifications. IEEE- 1394 refers to the IEEE foundation's 
specification number 1394 and all future revisions, 
derivations, and modifications of this specification. 

[0043] The invention can use one or more connectors of mixed 
types. For example, a system could use both a USB and 
IEEE-1394 connector simultaneously if one handset type 
required each connector. The important advantage this 
provides to the invention is the ability to readily adapt to 
any new connectors as they become standardized and 
readily available in this art. 

[0044] jhe invention can adopt other configurations well known 
in computer networking technology including a single 
stand-alone system. For example, the provisioning inter- 
face 10 can act as a server to multiple networked work 
stations equipped as described above for handset provi- 
sioning. Alternatively, an installation can employ multiple 
provisioning interfaces, with or without respective work 
stations. 

[0045] The manager setup tables of a preferred embodiment are 
used by a production manager to compile customer pur- 
chase orders termed Build Requests in the provisioning 
system. The Manager Tables include records listing hand- 
set manufacturing vendor names and respective vendor 



handset technologies; vendor model names and model 
numbers; customer names (radiotelephone service 
providers), customer address book numbers, and carrier 
types; and operator identification and provisioning inter- 
face identification. The Manager Setup Tables are com- 
piled by collecting the provisioning data files and program 
files for the vendors and customers from common access. 
The invention facilitates the compilation by a user over 
the network 18 shown in Fig. 1, accessing the subscriber 
databases SDBV 30, SDBS 40, and SDBD 50. 
[0046] The Application Collected Tables of a preferred embodi- 
ment (not shown) also include data entries for a Quality 
Assurance (QA) protocol. Quality Assurance is used to 
maximize provisioning efficiencies and, ultimately, cus- 
tomer satisfaction and convenience. For example, an Elec- 
tronic Serial Number (ESN) that is programmed into each 
handset of each Build Request is recorded in three 
database cells corresponding to initial data entry of the 
Build Request, an automated scan upon provisioning the 
handset, and an automated scan of the handset for Qual- 
ity Assurance. Such comparative data collection permits 
provisioned radiotelephone handsets to be closely tracked 
for conformance with Build Request specifications. 



[0047] The provisioning database 16 uses a foundation com- 
prised of Administrator Setup Tables outlined in Fig. 2. 
The Administrator Tables include reference data for Phone 
Setup 70 identifying vendors, phone makes and models, 
their technologies and operating software; Customer 
Setup 72 listing customer (service provider) identities and 
address references; Item Number Setup 74 cataloguing a 
cross reference that associates a vendor"s model of phone 
with a customer name and provisioning information for 
storage in the respective phone handsets; and User Setup 
76 naming personnel authorized to access the database to 
enter data into and use the provisioning system. Data en- 
tered in the Administrator Tables is accessed through the 
Manager Tables. 

[0048] The provisioning methods of a preferred embodiment use 
programming techniques well known in information tech- 
nology arts to program the Application Flow Phases for 
automated execution of provisioning. Any suitable pro- 
gramming technique can be utilized depending on the 
particular skill of the person implementing the program. 
The Application Phases store, collect, and transfer provi- 
sioning database information to initialize memory mod- 
ules in various particular phone handsets, using vendor- 



specific and carrier-specific files and information. Tlie 
Application Flow Phases comprise these particular phases 
of program routines: (a) Administrator Setup Phase, which 
is an information input task listing recognized vendors 
and customers; (b) Manager Build Setup Phase, which is an 
information input task defining customer Build Requests; 
(c) Operator Application Phase, which is an information 
transfer task to provision handsets for fulfilling customer 
Build Requests; and (d) Quality Assurance Phase, which is 
a verification task to check and record whether the Opera- 
tor Application phase has properly fulfilled Build Requests 
that were processed. 
[0049] The Administrator Setup Phase of a preferred embodiment 
is used to enter or edit data in the Administrator Setup ta- 
bles. This invention can be used to program any phone for 
which data is included in the database 16. Therefore, the 
Phone Setup table 70 of Fig. 2 is populated with data 
defining each phone model to be provisioned. For each 
radiotelephone handset service provider who is a cus- 
tomer of a provisioning center using this invention, the 
Customer Setup table 72 is completed for identifying the 
respective customers. Customers may designate that their 
Build Requests can be fulfilled using a plurality of makes 



and models of radiophone handsets. For each such desig- 
nation an Item Number Setup table 74 will be completed, 
giving cross-reference data linking the customer with 
specific phone models, and specifying appropriate provi- 
sioning information for the respective phone model to op- 
erate in the customer's service network. The User Setup 
table 76 identifies in-house personnel at the distribution 
center who are authorized to use the database 16 for data 
entry or product provisioning. 
[0050] The Manager Build Setup Phase of a preferred embodi- 
ment comprises entering data to the Manager Setup Ta- 
bles of the provisioning database 16 to define a Build Re- 
quest. The sequence of data input is illustrated in Fig. 3. 
The Manager Setup Tables automatically pick up data 
from Administrator Setup Tables corresponding to data 
identifying customers, vendors, and phone models. The 
data typically entered by a user for a Build Request in- 
cludes: production Build Request Number (PBR); quantity 
of phones to produce; customer selection of carrier type 
and customer ID; part number range; phone selection of 
manufacturer, technology, and model; Service Provider 
Codes, which can be pre-assigned by the manufacturer 
and/or service provider and/or randomly generated, e.g. 



Initial and Final Service Provider Code; Authentication Key 
or Keys, which can be pre-assigned by the manufacturer 
and/or service provider and/or randomly generated, e.g. 
Initial and Final Authentication Key. 

[0051] The Operator Application Phase of a preferred embodi- 
ment comprises interactions between a production as- 
sembly operator and the Application Flow program rou- 
tines through a provisioning interface. Fig. 4 illustrates 
the flow logic for Operator Application. The operator 
identifies Build Requests to be processed, and the pro- 
grams prompt the operator to select, connect/disconnect, 
and route respective handsets, by referencing the 
database 16 for specifications appropriate to the particu- 
lar Build Request numbers. While a phone is connected to 
the system, the programs collect and download provision- 
ing information to the handsets. The cycle is repeated, 
and the operator continues the handset selection process 
in fulfilling a Build Request. 

[0052] Additionally, the method has the capability to generate, 
capture and/or use the Service Programming Code (SPC) 
of each handset. The Service Programming Code is a code 
that is used to protect the phone from unauthorized pro- 
gramming. The SPC can be unique for each individual 



phone or common to a whole group of phones, depending 
on service provider preference. The Service Programming 
Code is also known by many other names in the industry 
including, but not limited to Master Sublock (MSL), Sub- 
sidy Programming Code, Lock Code, and Carrier Lock 
Code. The handset is usually provided with a default or 
pre-assigned SPC by the manufacturer, which can be re- 
programmed according to the service provider require- 
ments during the provisioning process. 

[0053] The automated method also has the ability to generate, 
capture and/or use the Authentication Key. The Authenti- 
cation Key (A-Key) is an encryption code used by some 
radiotelephone handset service providers to ensure that 
an individual handset is authorized for service on the ra- 
diotelephone handset service provider's network. The A- 
Key can be unique for each individual phone or common 
to a whole group of phones, depending on service 
provider preference. The handset is usually provided with 
a default or pre-assigned A-key by the manufacturer, 
which can be reprogrammed according to the service 
provider requirements during the provisioning process. 

[0054] The Quality Assurance ("QA") Phase of a preferred embod- 
iment entails evaluating the accuracy of fulfillment of the 



Build Requests, using a work station to cliecl< pliones pro- 
cessed in tlie "Operator Application" phase. Fig. 5 illus- 
trates a Quality Control ("QC") Check sequence that imple- 
ments the QA Phase, which typically flows as follows: En- 
ter Production Build Request; System instructs which 
phone to connect; Operator attaches handset; Query 
phone memory data followed by determination of pass/ 
fail status; if the handset passes, the handset is QC- 
stamped, packaged, released, and the process repeats it- 
self for the next handset; If the handset fails, the handset 
is marked as such and diverted to a non-conformance 
area and the process repeats itself for the next handset; 
upon all required handsets from a given build request be- 
ing tested, the system determines whether the build 
passed or failed; if the build passes, the non-conforming 
handsets are recycled back into production to be cor- 
rected; if the build fails, all handsets, both conforming 
and non-conforming handsets are placed in a non- 
conformance area for management action. 
[0055] The QA phase of the preferred embodiment will determine 
the build pass/fail using ANSI Quality tables for inspection 
based off ANSI Z 1.4 and includes any future modifica- 
tions, revisions, or superseding industry standard specifi- 



cations for inspection. 

[0056] The QC cliecl< in tlie QA phase of a preferred embodiment 
uses Application Phase program routines resident in the 
computer-controlled provisioning system. The QA pro- 
grams record conformance of the provisioning with Build 
Request specifications, and also record measurements of 
completeness of data installation according to specifica- 
tions in the Manager Setup Tables. The QA protocol maxi- 
mizes the delivery of compliant products, thereby mini- 
mizing costs for re-handling units returned by customers 
because of defective programming. Handsets can be 
checked individually or in mass batches corresponding to 
Build Requests. The provisioning interfaces can serve as 
both provisioning and QA sites. Thus, complete Build Re- 
quests can be processed at a single installation, using any 
station or a plurality of stations. 

[0057] Although a preferred embodiment uses the specific steps 
above to enter, store, and maintain the data required for 
the system to operate, the key elements of the invention 
that are offer the unique advantages of the current inven- 
tion are described below. 

[0058] The invention has no specific data requirements as the 
data requirements will depend on the given client or en- 



terprise and how it desires to provision tlie radiotele- 
plione handsets. There is a minimum requirement that the 
invention have some form of provisioning information. 
Provisioning information typically comprises provisioning 
data and instruction data. The provisioning method of this 
invention can program any radiotelephones for which de- 
sired instruction data and provisioning data is available 
and a compatible universal connector is installed in the 
provisioning interface. 
[0059] Any method that uses some or all of the provisioning in- 
formation described herein to automatically provision ra- 
diotelephone handsets is within the scope and spirit of 
the invention. 

[0060] Instruction data can include information required to pro- 
vision the phones. This information can include some or 
all of the following information: production build request 
number, quantity of phones to provision, carrier type, 
customer identification data, starting part number, final 
part number, handset manufacturer, handset technology 
type, handset model number, and the like, or a combina- 
tion thereof. 

[0061] Provisioning data can include information required to pro- 
vision the phone with all specific data and settings re- 



quired for a given radiotelephone handset carrier. This in- 
formation includes: roaming instructions, user features, 
number assignment module settings, browser and short 
messaging service settings, phone book entries, date 
book entries, message settings, carrier specific settings, 
user specific settings, default SPC; final SPC, default A- 
Key, final A-key, and combinations thereof. 
[0062] jhe provisioning data collected for this invention can be 
obtained from a plurality of information sources including 
but not limited to handset vendor databases and telecom- 
munication service provider databases. The provisioning 
information is also consolidated into a plurality of records 
comprising collected data matched to respective build re- 
quests. It is important to note that while one preferred 
embodiment contemplates the uses of databases for stor- 
ing and collecting various data, other sources of informa- 
tion suitable for the particular client needs would also be 
appropriate. 

[0063] While one preferred embodiment comprises the methods 
embodied in Application Flow Phases detailed above, 
other possible combinations of the required steps are 
within the scope and spirit of this invention. . The Flow 
Phases described above organize provisioning data and 



automate data transfer for high efficiency and accuracy. 
Another aspect of the inventive methods described above 
coordinate the provisioning of inventories of diverse ra- 
diophone handsets from multiple manufacturing vendors 
with the required diverse provisioning data from multiple 
phone service providers. This combination of organiza- 
tion, automation, and coordination improves the business 
of product delivery for both the vendors and service 
providers. 

[0064] Thus, the inventive provisioning system represents an im- 
provement over existing telecommunication hardware 
programming systems. This invention is highly auto- 
mated, and it provides the ability to automatically provi- 
sion handsets to varying customer specifications on a 
wide variety of radiotelephone handsets by different man- 
ufacturers. In addition, the system provides an automated 
Quality Assurance process to control production and dis- 
tribution of products with high levels of conformance. 
Furthermore, the system is not service provider, technol- 
ogy, or connector specific such that it can readily adapt to 
the ever changing radiotelephone handset market. 

[0065] Examples The following examples depict portions of one 
possible application used to implement the inventive ap- 



paratus and method. While this software application is 
particularly suited for the invention, this is not the only 
suitable embodiment contemplated by the invention and 
what is claimed. 

[0066] Example 1 The following tables depict portions of the Ap- 
plication Database 16. Table 1 illustrates an example of 
content in an Administrator Setup Table showing the User 
Setup Table. Table 2 illustrates part of an Item Number 
Setup Table. Table 3 illustrates part of a Manager Build 
Request Setup Table. Table 4 illustrates a first portion of 
an Application Collected Table for the Operator Phase, 
and Table 5 illustrates a second portion of an Application 
Collected Table, focusing on data for QA Phase results. 

[0067] Example 2 This example illustrates the flow logic for per- 
forming Administrator Setup in the application software 
that automatically guides users through the processes of 
this invention. As shown in Fig. 6, the first screen encoun- 
tered is "Start Application Software," which will direct a 
user into a mode of operation for administrative input, 
management input, or operator application to either pro- 
vision radiophone handsets or to perform the QA verifica- 
tion of provisioned products. To start and use the appli- 
cation software, the user must enter a name and pass- 



word. 

[0068] In Fig. 6, "Administrator" is selected. To enter tlie man- 
ager and operator functions discussed below, the user 
would make another appropriate selection in this screen. 
In Fig. 7 the Administrator Setup Main Screen offers 
choices of working in Administrator Setup Tables to define 
these data: Phone Manufacturer, Phone Model, Customer, 
Item Number, and User Setup. Figs. 8-12 depict the re- 
spective Administrator Setup data entry screens. 

[0069] Example 3 This example illustrates the flow logic for per- 
forming Manager Setup Phase tasks. The user enters the 
application software as described regarding Fig. 6 but se- 
lects the "manager" function. The application software will 
bring up a sequence of user screens depicted in Fig. 13, 
which shows the flow of the process of setting up a new 
Build Request. Fig. 14 shows an alternative screen se- 
quence that enables a user to edit the Application Data 
Tables for an existing Build Request. 



Table 1 - Administrator Setup Table 
User Setup Table 



NAME 


PASSWORD 


DATE 


LEVEL 


adminl 


pwl 


03-NOV-04 


Administrator 


mgrl 


pw2 


03-NOV-04 


Manager 






03-NOV-04 


User 



Table 2 - Administrator Setup Tables 
Item Number Setup Table 



NAM SCM 


BROWSER IP 


GRAPHIC 


MIN 


MDN 


VCODER 


BANNER 


BREW 


246 


192.268.0.1 


ISPl 


Default 


Default 


2 


Brand 1 




246 


150.255.4 


ISP2 


Default 


Default 


2 


Brdnd2 


Ready 


246 


0.0.0.0 


MFRl 


Default 


Default 


2 


Brands 


Not Ready 



Table 3 - Application Data Tables 
Manager Build Request Setup 



BUILD 
REQUEST NO. 


MANAGER 


DATE 


1_PART_NUM 


FINAL 


TECH 


SW_VER 


PRL_VER 


800123 


mgrl 


03-NOV-03 


135212 


135546 


CDMA 


2200.01.35 


96 


800321 


mgrl 


03-NOV-03 


135212 


135214 


CDMA 


2200.01.35 


50097 


800546 


mgrl 


03-NOV-03 


135212 


135557 


CDMA 


2200.01.35 


400 



Table 3 - Application Data Tables 
Manager Build Request Setup (continued) 



QA % 


CUSTOMER 


MFG 


MODEL 


GRAPHIC 


CUSTOMER 


QUANTITY 


25 


ISPl 


MFRl 


MDLl 


GRAPHICI 


ISPl 


2500 


20 


ISP2 


MFRl 


MDLl 


GRAPH1C2 


ISP2 


3500 


100 


ISP3 


MFRl 


MDLl 


GRAPHICS 


ISP3 


750 



Table 4 - Application Data Tables 
Application Collected Table - Operator Phase 



USER 


TABLE 


DATE PRG 


BUILD PRG 


TOTAL PRG 


QA FAIL 




A4 


07-NOV-03 


800123 


1250 


0 


userl 


C3 


07-NOV-03 


800321 


523 


0 


xiserl 


E7 


07-NOV-03 


800546 


66 


2 



Table 5 - Application Data Tables 
Application Collected Table - QA Phase 



BUILD 


ESN 


PRL 


sw 




ESN PHONE 


BOX 
LABEL 


DATEQA 


BUILD REQUEST 
QA RESULT 


800123 


13012345678 


PASS 


PASS 


13012345678 


13012345678 


135546 


07-NOV-03 


PASS 


800321 


15965412365 


PASS 


PASS 


15965412365 


15965412365 


135214 


07-NOV-03 


PASS 


800546 


25401258746 


FAIL 


PASS 


25401258746 


25401258746 


135557 


07-NOV-03 


PASS 



[0070] Example 4 This example illustrates the flow logic for per- 
forming Operator Application Phase tasks. The user enters 
the application software as described regarding Fig. 6 but 
now selects the "operator" function. The application soft- 



ware will bring up a sequence of user screens shown in 
Fig. 15, which shows the flow of the process of selecting a 
Build Request and proceeding to provision phone units to 
fulfill the respective customer's order. 

[0071] Example 5 This example illustrates the flow logic for per- 
forming Quality Assurance Phase tasks. Quality Assurance 
is also a function performed by an operator. The user en- 
ters the application software as described regarding Fig. 6 
but now selects the "QA" function. The application soft- 
ware will bring up a sequence of user screens shown in 
Fig. 16, which shows the flow of the process of selecting a 
Build Request and proceeding to apply the QA checking 
procedures to phone units provisioned for the respective 
customer's order. 

[0072] jhe invention is described above with reference to non- 
limiting examples provided for illustrative purposes only. 
In view thereof, various modifications and changes will 
become apparent to one of ordinary skill in the art. The 
invention does not require that the application software to 
perform the inventive method be done in exactly the same 
way to still be within the spirit and scope of the invention. 
It is intended that all such changes and modifications are 
within the scope and spirit of the appended claims. 



